Many software programs that accept user-generated inputs to process instructions include a parser as a basic feature of the software front end. A parser analyzes a sentence or language statement and breaks down words and symbols into functional units that can be converted into machine language. Many software programs have customized parsers written specifically for the purpose of the application where they reside. Thus every time a new application is authored, the parser may also require a rewrite because the embedded and customized parser written in a former application is too specific to the embedded application for generalized new use. This occurs frequently when parsers are embedded into compilers. A reusable and portable parser that is componentized could have benefits with respect to easing the programming burden associated with new applications and the added benefit of user familiarity from one new application to the next.
In a multiple database environment, programmers may be asked to make updates to multiple databases. Input statements to such applications as database management tools are often complex if programmers are asked to make multiple database changes. It is desirable to establish a more time and effort efficient technique of performing such multiple tasks with a single input script. For example, given an environment in which a user has to update one thousand rows of data on three separate servers, each server having five databases, the input statement can be quite large. In this instance, the user may have to generate a script that supplies the 1000 data changes, connect to a first server, run the script five times, once for each database on the server, disconnect from the server, connect to a second server, run the script another five times, once for each database, disconnect from the server, connect to a third server, and run the script another five times for the five databases in the third server. If the script being used is executed in a linear fashion, the user must generate at least 15,000 script lines; 1000 data change lines for three servers, each having five databases. Clearly, such script generation is a burden on the programming user. However, if a user were to create a generic script that contained special constructs understood by a script execution environment, this extra work of duplicating data 15 times could be saved. In that instance, a special parser may be needed in the execution environment to understand these special constructs. Although each execution environment can implement its own parser, such an approach could be unnecessarily costly and error prone because different implementations of the environment and the parser would behave slightly differently.
Thus, there is a need for a reusable componentized parser for use in a multiplicity of different applications. In addition, it would also be useful for the componentized parser to have features that further lessen the burden on programmers to provide extensive input statement simplifications in order for the parser to perform multiple tasks easily. The present invention addresses the aforementioned needs and solves them with additional advantages as expressed herein.